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The tel URI for Telephone Numbers 


Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2004). 

Abstract 
This document specifies the URI (Uniform Resource Identifier) scheme 
"tel". The "tel" URI describes resources identified by telephone 


numbers. This document obsoletes RFC 2806. 
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1. Introduction 


This document defines the URI scheme "tel", which describes resources 
identified by telephone numbers. A telephone number is a string of 
decimal digits that uniquely indicates the network termination point. 
The number contains the information necessary to route the call to 
this point. (This definition is derived from [E.164] but encompasses 
both public and private numbers.) 


The termination point of the "tel" URI telephone number is not 
restricted. It can be in the public telephone network, a private 
telephone network, or the Internet. It can be fixed or wireless and 
address a fixed wired, mobile, or nomadic terminal. The terminal 
addressed can support any electronic communication service (ECS), 
including voice, data, and fax. The URI can refer to resources 
identified by a telephone number, including but not limited to 
originators or targets of a telephone call. 


The "tel" URI is a globally unique identifier ("name") only; it does 
not describe the steps necessary to reach a particular number and 
does not imply dialling semantics. Furthermore, it does not refer to 


a specific physical device, only to a telephone number. 


As commonly understood, telephone numbers comprise two related but 
distinct concepts: a canonical address-of-record and a dial string. 
We define the concepts below: 


Address-of-record or identifier: The telephone number is understood 
here as the canonical address-of-record or identifier for a 
termination point within a specific network. For the public 
network, these numbers follow the rules in E.164 [E.164], while 
private numbers follow the rules of the owner of the private 
numbering plan. Subscribers publish these identifiers so that 
they can be reached, regardless of the location of the caller. 
(Naturally, not all numbers are reachable from everywhere, for a 
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variety of technical and local policy reasons. Also, a single 
termination point may be reachable from different networks and may 
have multiple identifiers.) 


Dial string: "Dial strings" are the actual numbers, symbols, and 
pauses entered by a user to place a phone call. A dial string is 
consumed by one or more network entities and understood in the 
context of the configuration of these entities. It is used to 
generate an address-of-record or identifier (in the sense 
described above) so that a call can be routed. Dial strings may 
require prepended digits to exit the private branch exchange (PBX) 
the end system is connected to, and they may include post-dial 
dual-tone multi-frequency (DTMF) signaling that could control an 
interactive voice response (IVR) system or reach an extension. 
Dial strings are beyond the scope of this document. 


Both approaches can be expressed as a URI. For dial strings, this 
URI is passed to an entity that can reproduce the actions specified 
in the dial string. For example, in an analog phone system, a dialer 
translates the dial string into a sequence of actions such as waiting 
for dial tone, sending DTMF digits, pausing, and generating post-dial 
DIMF digits after the callee picks up. In an integrated services 
digital network (ISDN) or ISDN user part (ISUP) environment, the 
signaling elements that receive protocol messages containing the dial 
string perform the appropriate protocol actions. As noted, this 
approach is beyond the scope of this specification. 


The approach described here has the URI specify the telephone number 
as an identifier, which can be either globally unique or only valid 
within a local context. The dialling application is aware of the 
local context, knowing, for example, whether special digits need to 
be dialed to seize an outside line; whether network, pulse, or tone 
dialling is needed; and what tones indicate call progress. The 
dialling application then converts the telephone number into a dial 
sequence and performs the necessary signaling actions. The dialer 
does not have to be a user application as found in traditional 
desktop operating systems but could well be part of an IP-to-PSTN 
gateway. 


To reach a telephone number from a phone on a PBX, for example, the 
user of that phone has to know how to convert the telephone number 
identifier into a dial string appropriate for that phone. The 
telephone number itself does not convey what needs to be done for a 
particular terminal. Instructions may include dialling "9" before 
placing a call or prepending "00" to reach a number in a foreign 
country. The phone may also need to strip area and country codes. 
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The identifier approach described in this document has the 
disadvantage that certain services, such as electronic banking or 
voicemail, cannot be specified in a "tel" URI. 


The notation for phone numbers in this document is similar to that in 
RFC 3191 [RFC3191] and RFC 3192 [RFC3192]. However, the syntax 
differs as this document describes URIs whereas RFC 3191 and RFC 3192 
specify electronic mail addresses. RFC 3191 and RFC 3192 use "/" to 
indicate parameters (qualifiers). Since URIs use the forward slash 
to describe path hierarchy, the URI scheme described here uses the 
semicolon, in keeping with Session Initiation Protocol (SIP) URI 
conventions [RFC3261]. 


The "tel" URI can be used as a request URI in SIP [RFC3261] requests. 
The SIP specification also inherits the ’subscriber’ part of the 
syntax as part of the ’user element’ in the SIP URI. Other protocols 
may also use this URI scheme. 


The "tel" URI does not specify the call type, such as voice, fax, or 
data call, and does not provide the connection parameters for a data 


call. The type and parameters are assumed to be negotiated either 
in-band by the telephone device or through a signaling protocol such 
as SIP. 


This document obsoletes RFC 2806. 
2. Terminology 


In this document, the key words "MUST", "MUST NOT", "REQUIRED", 
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 
and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 
2119, [RFC2119] and indicate requirement levels for compliant 
implementations. 


3. URI Syntax 


The URI is defined using the ABNF (augmented Backus-Naur form) 
described in RFC 2234 [RFC2234] and uses elements from the core 
definitions (appendix A of RFC 2234). 


The syntax definition follows RFC 2396 [RFC2396], indicating the 
actual characters contained in the URI. If the reserved characters 
"+", ";", m=", and "?" are used as delimiters between components of 
the "tel" URI, they MUST NOT be percent encoded. These characters 
MUST be percent encoded if they appear in tel URI parameter values. 
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Characters other than those in the "reserved" and "unsafe" sets (see 
RFC 2396 [RFC2396]) are equivalent to their "% HEX HEX" percent 
encoding. 


The "tel" URI has the following syntax: 


telephone-uri = "tel:" telephone-subscriber 
telephone-subscriber = global-number / local-number 
global-number = global-number-digits *par 

local-number = local-number-digits *par context *par 
par = parameter / extension / isdn-subaddress 
isdn-subaddress = "sisub=" 1*uric 

extension = ";ext="_1*phonedigit 

context = ";phone-context=" descriptor 

descriptor = domainname / global-number-digits 
global-number-digits = "+" *phonedigit DIGIT *phonedigit 


local-number-digits = 
*phonedigit-hex (HEXDIG / "*" / "#") *phonedigit—hex 


domainname = *( domainlabel "." ) toplabel [ "." ] 
domainlabel = alphanum 

/ alphanum *( alphanum / "-" ) alphanum 
toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum 
parameter = ";" pname ["=" pvalue ] 
pname = 1*( alphanum / "-" ) 
pvalue = 1*paramchar 
paramchar = param-unreserved / unreserved / pct-encoded 
unreserved = alphanum / mark 
mark - ww / pian / wow / wow / "~n / wee / 

LE E L / " (Gu / ") " 
pct-—encoded = "S" HEXDIG HEXDIG 
param-unreserved = wpn / a a / UPA / "n / "g" / "n / vom 
phonedigit = DIGIT / [ visual-separator ] 
phonedigit-hex = HEXDIG / "*" / "#" / [ visual-separator ] 
visual-separator = wow / wow / nn / wyn 
alphanum = ALPHA / DIGIT 
reserved = wan / "wyn / wow / "n / wan / we / 

wow / "m / no / mean 
uric = reserved / unreserved / pct-encoded 


Each parameter name ("pname"), the ISDN subaddress, the ’extension’, 
and the ’context’ MUST NOT appear more than once. The ’isdn- 
subaddress’ or ’extension’ MUST appear first, if present, followed by 
the ‘context’ parameter, if present, followed by any other parameters 
in lexicographical order. 


This simplifies comparison when the "tel" URI is compared 
character by character, such as in SIP URIs [RFC3261]. 
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4. 


URI Comparisons 
Two "tel" URIs are equivalent according to the following rules: 


o Both must be either a ’local-number’ or a ’/global-number’, i.e., 
start with a ’+’. 

o The ’global-number-digits’ and the ’local-number-digits’ must be 
equal, after removing all visual separators. 

o For mandatory additional parameters (section 5.4) and the ’phone- 
context’ and ’extension’ parameters defined in this document, the 
‘phone-context’ parameter value is compared as a host name if it 
is a ’domainname’ or digit by digit if it is ’global-number- 
digits’. The latter is compared after removing all ’/visual- 
separator’ characters. 

o Parameters are compared according to ’pname’, regardless of the 
order they appeared in the URI. If one URI has a parameter name 
not found in the other, the two URIs are not equal. 

o URI comparisons are case-insensitive. 


All parameter names and values SHOULD use lower-case characters, as 
tel URIs may be used within contexts where comparisons are case 
sensitive. 


Section 19.1.4 in the SIP specification [RFC3261] discusses one such 
case. 


Phone Numbers and Their Context 


Slee Phone Numbers 


The ’telephone-subscriber’ part of the URI indicates the number. The 
phone number can be represented in either global (E.164) or local 
notation. All phone numbers MUST use the global form unless they 
cannot be represented as such. Numbers from private numbering plans, 


emergency ("911", "112"), and some directory-assistance numbers 
(e.g., "411") and other "service codes" (numbers of the form N11 in 
the United States) cannot be represented in global (E.164) form and 
need to be represented as a local number with a context. Local 


numbers MUST be tagged with a ’/phone-context’ (section 5.1.5). 


Implementations MUST NOT assume that telephone numbers have a 
maximum, minimum, or fixed length, or that they always begin with or 
contain certain digits. 
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5.1.1. Separators in Phone Numbers 


Phone numbers MAY contain visual separators. Visual separators 
(’visual-separator’) merely aid readability and are not used for URI 
comparison or placing a call. 


Although it complicates comparisons, this specification retains 
visual separators in order to follow the spirit of RFC 2396 
[RFC2396], which remarks that "A URI often needs to be remembered by 
people, and it is easier for people to remember a URI when it 


consists of meaningful components". Also, ISBN URNs documented in 
RFC 3187 [RFC3187] use visual separators in a manner similar to this 
specification. 


However, even though ITU-T E.123 [E.123] recommends the use of space 
characters as visual separators in printed telephone numbers, "tel" 
URIs MUST NOT use spaces in visual separators to avoid excessive 
escaping. 


5.1.2. Alphabetic Characters Corresponding to Digits 


In some countries, it is common to write phone numbers with 
alphabetic characters corresponding to certain numbers on the 
telephone keypad. The URI format does not support this notation, as 
the mapping from alphabetic characters to digits is not completely 
uniform internationally, although there are standards [E.161] [T1.703] 
addressing this issue. 


5.1.3. Alphabetic, *, and # Characters as Identifiers 


As called and calling terminal numbers (TNs) are encoded in BCD in 
ISUP, six additional values per digit can be encoded, sometimes 
represented as the hexadecimal characters A through F. Similarly, 
DTMF allows for the encoding of the symbols *, #, and A through D. 
However, in accordance with E.164, these may not be included in 
global numbers. Their meaning in local numbers is not defined here, 
but they are not prohibited. 


5.1.4. Global Numbers 


Globally unique numbers are identified by the leading "+" character. 
Global numbers MUST be composed with the country (CC) and national 
(NSN) numbers as specified in E.123 [E.123] and E.164 [E.164]. 
Globally unique numbers are unambiguous everywhere in the world and 
SHOULD be used. 
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5.1.5. Local Numbers 


Local numbers are unique only within a certain geographical area or a 
certain part of the telephone network, e.g., a private branch 
exchange (PBX), a state or province, a particular local exchange 
carrier, or a particular country. URIs with local phone numbers 
should only appear in environments where all local entities can 
successfully set up the call by passing the number to the dialling 
software. Digits needed for accessing an outside line, for example, 
are not included in local numbers. Local numbers SHOULD NOT be used 
unless there is no way to represent the number as a global number. 


Local numbers SHOULD NOT be used for several reasons. Local numbers 
require that the originator and recipient are configured 
appropriately so that they can insert and recognize the correct 
context descriptors. Since there is no algorithm to pick the same 
descriptor independently, labelling numbers with their context 
increases the chances of misconfiguration so that valid identifiers 
are rejected by mistake. The algorithm to select descriptors was 
chosen so that accidental collisions would be rare, but they cannot 
be ruled out. 


Local numbers MUST have a ’phone-context’ parameter that identifies 
the scope of their validity. The parameter MUST be chosen to 
identify the local context within which the number is unique 
unambiguously. Thus, the combination of the descriptor in the 
‘phone-context’ parameter and local number is again globally unique. 
The parameter value is defined by the assignee of the local number. 
It does NOT indicate a prefix that turns the local number into a 
global (E.164) number. 


There are two ways to label the context: via a global number or any 
number of its leading digits (e.g., "+33") and via a domain name, 
e.g., "houston.example.com". The choice between the two is left to 
the "owner" of the local number and is governed by whether there is a 
global number or domain name that is a valid identifier fora 
particular local number. 


The domain name does not have to resolve to any actual host but MUST 
be under the administrative control of the entity managing the local 
phone context. 


A global number context consists of the initial digits of a valid 
global number. All global numbers with these initial digits must be 
assigned to the same organization, and no such matching number can be 
used by any other organization. For example, +49-6151-16 would be a 
suitable context for the Technical University of Darmstadt, as it 
uses all numbers starting with those digits. If such an initial 
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string of digits does not exist, the organization SHOULD use the 
lowest number of the global number range assigned to it. (This can 
occur if two organizations share the same decimal block of numbers. 
For example, assume an organization owns the number range +1-212- 
555-0100 through +1-212-555-0149. +1-212-555-1 would not be a valid 
global number context, but +1-212-555-0100 would work.) It is not 
required that local numbers within the context actually begin with 
the chosen set of initial numbers. 


A context consisting of the initial digits of a global number does 
not imply that adding these to the local number will generate a valid 
E.164 number. It might do so by coincidence, but this cannot be 
relied upon. (For example, "911" should be labeled with the context 
"41", but "+1-911" is not a valid E.164 number.) 


National freephone numbers do not need a context, even though they 
are not necessarily reachable from outside a particular country code 
or numbering plan. Recall that "tel" URIs are identifiers; it is 
sufficient that a global number is unique, but it is not required 
that it be reachable from everywhere. 


Even non-freephone numbers may be out of date or may not be 
reachable from a particular location. For example, premium 
services such as "900" numbers in the North American numbering 
plan are often not dialable from outside the particular country 
code. 


The two label types were chosen so that, in almost all cases, a 
local administrator can pick an identifier that is reasonably 
descriptive and does not require a new IANA-managed assigned 
number. It is up to the administrator to assign an appropriate 
identifier and to use it consistently. Often, an organization can 
choose among several different identifiers. 


If the recipient of a "tel" URI uses it simply for identification, 
the receiver does not need to know anything about the context 
descriptor. It simply treats it as one part of a globally unique 
identifier, with the other being the local number. If a recipient of 
the URI intends to place a call to the local number, it MUST 
understand the context and be able to place calls within that 
context. 


5.2. ISDN Subaddresses 


A phone number MAY also contain an ’isdn-subaddress’ parameter that 
indicates an ISDN subaddress. 
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ISDN subaddresses typically contain International Alphabet 5 (IA5 
[T.50]) characters but may contain any octet value. 


5.3. Phone Extensions 


Phone extensions identify stations behind a non-ISDN PBX and are 
functionally roughly equivalent to ISDN subaddresses. They are 
identified with the ’extension’ parameter. At most, one of the 
‘isdn-subaddress’ and ’extension’ parameters can appear ina "tel" 
URI, i.e., they cannot appear both at the same time. 


5.4. Other Parameters 


Future protocol extensions to this URI scheme may add other 
parameters (’parameter’ in the ABNF). Such parameters can be either 
mandatory or optional. Mandatory parameters start with "m-". An 
implementation MAY ignore optional parameters and MUST NOT use the 
URI if it contains unknown mandatory parameters. The "m-" prefix 
cannot be added to parameters that were already registered (except to 
create a new, logically distinct parameter). The "phone-context" 
parameter in this document is mandatory, and "isub" and "ext" are 
optional. 


New mandatory parameters must be described in a standards-track RFC, 
but an informational RFC is sufficient for optional parameters. 


For example, /’/parameter’ parameters can be used to store 
application-specific additional data about the phone number, its 
intended use, or any conversions that have been applied to the 
number. 


Entities that forward protocol requests containing "tel" URIs with 
optional parameters MUST NOT delete or modify parameters they do not 
understand. 


6. Examples 
tel:+1-201-555-0123: This URI points to a phone number in the United 
States. The hyphens are included to make the number more human 


readable; they separate country, area code and subscriber number. 


tel:7042;phone-context=example.com: The URI describes a local phone 
number valid within the context "example.com". 


tel:863-1234; phone-context=+1-914-555: The URI describes a local 
phone number that is valid within a particular phone prefix. 
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7. Rationale 
7.1. Why Not Just Put Telephone Numbers in SIP URIs? 


The "tel" URI describes a service, reaching a telephone number, that 
is independent of the means of doing so, be it via a SIP-to-PSTN 
gateway, a direct SIP call via E.164 number ("ENUM") translation 
[RFC3761], some other signaling protocols such as H.323, ora 
traditional circuit-switched call initiated on the client side via, 
say, the Telephony Application Programming Interface (TAPI). Thus, 
in spirit, it is closer to the URN schemes that also leave the 
resolution to an external mechanism. The same "tel" URI may get 
translated to any number of other URIs in the process of setting up 
the call. 


7.2. Why Not Distinguish between Call Types? 


Signaling protocols such as SIP allow negotiating the call type and 
parameters, making the very basic indication within the URI scheme 
moot. Also, since the call type can change frequently, any such 
indication in a URI is likely to be out of date. If such designation 
is desired for a device that directly places calls without a 
signaling protocol such as SIP, mechanisms such as the "type" 
attribute for the "A" element in HTML may be more appropriate. 


7.3. Why "tel"? 


"tel" was chosen because it is widely recognized that none of the 
other suggestions appeared appropriate. "Callto" was discarded 
because URI schemes locate a resource and do not specify an action to 
be taken. "Telephone" and "phone" were considered too long and not 
easily recognized internationally. 


7.4. Do Not Confuse Numbers with How They Are Dialed 
As an example, in many countries the E.164 number "+1-212-555-3141" 
will be dialed as 00-1-212-555-3141, where the leading "00" is a 
prefix for international calls. (In general, a "+" symbol in E.164 
indicates that an international prefix is required.) 


8. Usage of Telephone URIs in HTML 


Links using the "tel" URI SHOULD enclose the telephone number so that 
users can easily predict the action taken when following the link 


Dial <a href="tel:+1-212-555-0101">+1-212-555-0101</a> for 
assistance. 


Schulzrinne Standards Track [Page 11] 


RFC 3966 The tel URI December 2004 


instead of 
Dial <a href="tel:+1-212-555-0101">this number</a> for assistance. 


On a public HTML page, the telephone number in the URI SHOULD always 
be in the global form, even if the text of the link uses some local 
format: 


Telephone (if dialling in the United States): 
<a href="tel:+1-201-555-0111">(201) 555-0111</a> 


or even 


For having RFCs read aloud, call <a 
href="tel:+1-555-438-3732">1-555-IETF-RFC</a>. 


9. Use of "tel" URIs with SIP (Informative) 


SIP can use the "tel" URI anywhere a URI is allowed, for example as a 
Request-URI, along with "sip" and "Sips" URIs. For brevity, we will 
imply "sips" URIs when talking about SIP URIs. Both "tel" and SIP 
URIs can contain telephone numbers. In SIP URIs, they appear as the 
user part, i.e., before the @ symbol (section 19.1.6 in [RFC3261]). 


Unless a SIP UA connects directly to a PSTN gateway, one of the SIP 
proxy servers has to translate the "tel" URI to a SIP URI, with the 
host part of that URI pointing to a gateway. Typically, the outbound 
proxy server, as the first proxy server visited by a call request, 
performs this translation. A proxy server can translate all "tel" 
URIs to the same SIP host name or select a different gateway for 
different "tel" prefixes, based, for example, on information learned 
from TRIP [RFC3219]. However, a proxy server could also delegate 
this translation task to any other proxy server, as proxy servers are 
free to apply whatever routing logic they desire. For local numbers, 
the proxy MUST NOT translate "tel" URIs whose contexts it does not 
understand. 


As noted earlier, all phone numbers MUST use the global form unless 
they cannot be represented as such. If the local-number format is 
used, it MUST be qualified by the ’phone-context’ parameter. 
Effectively, the combination of local number and phone context makes 
the "tel" URI globally unique. 


Although web pages, vCard business cards, address books, and 
directories can easily contain global "tel" URIs, users on twelve- 
button (IP) phones cannot dial such numbers directly and are 
typically accustomed to dialling shorter strings, e.g., for PBX 
extensions or local numbers. These so-called dial strings (section 
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1) are not directly represented by "tel" URIs, as noted. We refer to 
the rules that govern the translation of dial strings into SIP and 
"tel" URIs, global or local, as the dial plan. Currently, 
translations from dial strings to "tel" URIs have to take place in 


end systems. Future efforts may provide means to carry dial strings 
in a SIP URI, for example, but no such mechanisms exist as of this 
writing. 


A SIP UA can use a dial plan to translate dial strings into SIP or 
"tel" URIs. The dial plan can be manually configured or, preferably, 
downloaded as part of a device configuration mechanism. (At this 
time, there is no standardized mechanism for this.) 


A mobile user can use at least two dial plans, namely the dial plan 
for the network that he is currently visiting and the dial plan for 
his home network. Generally, dialed numbers meant to represent 
global numbers will look the same after the translation regardless of 
the dial plan, even if, say, the visited network uses ’0’ for 
dialling an ‘outside’ number and the user’s home network uses ’9’, as 
long as the user is aware of the current dial plan. However, local 
extensions without a direct global equivalent may well behave 
differently. To avoid any ambiguity, the dial plan MUST insert a 
suitable /’/phone-context’ string when performing the translation. If 
the ’phone-context’ is a domain name, there are three cases: 


1. The outbound proxy recognizes the domain name in the "tel" or SIP 
URI as its local context and can route the request to a gateway 
that understands the local number. 


2. The outbound proxy does not use the same phone context but can 
route to a proxy that handles this phone context. This routing 
can be done via a lookup table, or the domain name of the phone 
context might be set up to reflect the SIP domain name of a 
suitable proxy. For example, a proxy may always route calls with 
"tel" URIs like 


tel:1234;phone-context=munich.example.com 


to the SIP proxy located at munich.example.com. (Proxies 
receiving a tel URI with a context they do not understand are 
obligated to return a 404 (Not Found) status response so that an 
outbound proxy may decide to attempt such a heuristic.) 


3. The outbound proxy does not recognize the phone context and 
cannot find the appropriate proxy for that phone context. In 
that case, the translation fails, and the outbound proxy returns 
a 404 (Not Found) error response. 
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Security Considerations 


The security considerations parallel those for the mailto URL 
[RFC2368]. 


Web clients and similar tools MUST NOT use the "tel" URI to place 
telephone calls without the explicit consent of the user of that 
client. Placing calls automatically without appropriate user 
confirmation may incur a number of risks, such as those described 
below: 


o Calls may incur costs. 

o The URI may be used to place malicious or annoying calls. 

o A call will take the user's phone line off-hook, thus preventing 
its use. 

o A call may reveal the user’s possibly unlisted phone number to the 
remote host in the caller identification data and may allow the 
attacker to correlate the user’s phone number with other 
information, such as an e-mail or IP address. 


This is particularly important for "tel" URIs embedded in HTML links, 
as a malicious party may hide the true nature of the URI in the link 
text, as in 


<a href="tel:+1-900-555-0191">Find free information here</a> 
<a href="tel:+1-900-555-0191">tel:+1-800-555-0191</a> 


"tel" URIs may reveal private information, similar to including phone 
numbers as text. However, the presence of the tel: schema identifier 
may make it easier for an adversary using a search engine to discover 
these numbers. 


Changes Since RFC 2806 


The specification is syntactically backwards-compatible with the 
"tel" URI defined in RFC 2806 [RFC2806] but has been completely 
rewritten. This document more clearly distinguishes telephone 
numbers as identifiers of network termination points from dial 
strings and removes the latter from the purview of "tel" URIs. 
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Compared to RFC 2806, references to carrier selection, dial context, 
fax and modem URIs, post-dial strings, and pause characters have been 
removed. The URI syntax now conforms to RFC 2396 [RFC2396]. 

A section on using "tel" URIs in SIP was added. 
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